To keep an organized code structure.
## Code Documentation  ##

* [SD FAT32 lib](#SD_FAT32_lib)
* [Datalogger module](#datalogger)
* [Sensors Management](#Sensors)
 * [Implemented Sensors so far](#ImplementedSensors) 
 * [HOW TO - Add a new sensor](Docu/NewSensor.md) (you can help writing more sensors drivers)
* [Program Memory strings management](#ProgMemStrings)

<h6 id="SD_FAT32_lib"> </h6>
### SD FAT 32 lib ###

[FAT32.h](FAT32.h) and [FAT32.c](FAT32.c) 

<h6 id="datalogger"> </h6>
### Datalogger ###

The function of this is to make it easier to log samples taken from
sensors into memory (SD_card).

* [Datalogger.h](Datalogger.h) Definitions for the Datalogger
* [Datalogger.c](Datalogger.c) Implementation of functions for the Datalogger, the main function is `LogIntoFile` which *reads* each
sensor's response first checking if its flag is enabled (see
[Sensors Flags](#SensorsFlags)). If a sensor `control flag` is
enabled the corresponding sensor [get_response](#SensorsGetResponse) function is called and check if the sensor is responsive. If
everything is ok, then the sensor's response is logged into a file.

The Datalogger system is an implementation of [Docu/datalog_format](Docu/datalog_format)

<h6 id="Sensors"> </h6>
### Sensors ###

<h6 id="ImplementedSensors"> </h6>
#### Implemented Sensors ####

* dht11 see [dht11.h](dht11.h) and [dht11.c](dht11.c) (measures temperature and relative humidity)

<h6 id="FunctionsToImplement"> </h6>
#### Functions a sensor should implement ####

All implemented sensors should be included in [sensors.h](sensors.h)
And Write its name to file [ProgMemStrings.h](ProgMemStrings.h) inside an array
corresponding to the physical phenomenon it measures.

 There are certain functions that a sensor should implement to
 make it easier to log sensor's response into a file using
 [Datalogger.c](Datalogger.c)

##### Initialization #####

`char [sensor_name]_init() `

  Initializes the sensor, returns 0 if initialization OK
  non-zero means error.
  This function setup hardware and ports on the micro, then calls
  *enable* function to read the sensor response and log it. 
  
  If initialization fails no action it returns non-zero (error)

##### Enable #####

`void [sensor_name]_enable()`
  
  Sets the flags to read the sensor's response, so it will be
  logged in .l and if available .r files
  
##### Disable #####

`void [sensor_name]_disable()`
  
  Clear the flags to stop reading the sensor's response, when
  cleared the micro *does not take any action* related to this
  sensor so no data corresponding to this sensor will be logged.
  
<h6 id="SensorsGetResponse"> </h6>
##### Get response #####

`float [sensor_name]_get_<physical_phenomenom>()`

  Reads the sensor answer, this function calculates the response
  for human readeable format to log this response in the .l file.
  The variable `response` of the sensor is modified.
  
  If the *sensor reading fails* it is returned SENSOR_NO_ANSWER
  
##### Get Raw Response (optional) #####

`float [sensor_name]_getRAW_<physical_phenomenon>()`
  
  Returns RAW response of the sensor if available, this data will
  be logged to the .r file.
  The var `raw_response` is modified

  If the *sensor reading fails* it is returned SENSOR_NO_ANSWER

##### Get Sensor physical phenomenon name (optional) #####

`unsigned char [sensor_name]_PhyisicalPhenIndex()`

  Returns the index to the sensor physical phenomenon string in the file `sensors_flags`

<h6 id="SensorsFlags"> </h6>
#### Sensors flags ####

A sensor has a flag that represents if the sensor has been activated
to be used, this is the `control flag` and if it is 1 means the
device was marked to read its response and log into memory (SD_card)

The `control flag` is set or cleared by the user through a computer
via serial interface (USART).

To keep `control flag` the same after a poweroff it is used the
EEPROM memory of the micro.

<h6 id="ProgMemStrings"> </h6>
### Program Memory strings ###

- All strings stored on PROGRAM MEMORY are defined in `ProgMemStrings.h`
- A file [ProgMemLink.h](ProgMemLink.h) serves as a way to get PROGMEM strings and that those strings could be present into different modules.
- See avr-libc-user-manual-1.8.0 for reference
